1. Field of the Invention
The invention relates to database systems, and more particularly, to a customizable database system communicating between transactional and processing database units retaining code in uncompiled form to increase efficiency.
2. Description of the Related Art
Databases are widely used by organizations to manage copious amounts of information accumulated in the course of operations. Large amounts of information dictate the use of large, specialized, and often very complex database applications.
In general, additional software installation creates upheaval within an organization. In the process of new software installation, tasks that should be automated are not accounted for by the generic software resulting in tasks that should be automated being relegated to inefficient manual processing. The costs of incorporating automated processes for those not covered by generic software, that if in place would profoundly enhance organizational efficiencies, are often prohibitive and therefore retained as manual tasks. As a result, the installation of software intended to enhance efficiency institutionalizes inefficiencies associated with tasks not contemplated when the software was written.
In order to develop a product that can be deployed across a variety of organizations that vary widely in organizational structure, personnel numbers, personnel expertise, creativity requirements, goals and even physical office layout, currently one must select a software option from among the vendor options available. The option selected is either superior to, or representative of, a population of vendor options available.
Unfortunately, too many specific processes of a particular organization are unaddressed due to the cost associated with developing software to address those specific processes. The time associated with a programmer learning an organization-specific process and developing a custom application to address that process sacrifices true strategic potential to address manual processes because the cost benefit analysis of custom software is unfavorable. The current requirement to hire an individual for the sole purpose of supporting a software package intended to impart efficiency on an organization contravenes that goal. Unfortunately, it is usually the case that the breakthrough efficiencies possible are rarely achieved due to the inordinate number of problems that arise when a generic software package is force fit into a specific process of an organization.
It is a central premise of market economies that software products must possess consistent, identical architecture in order to control production and delivery costs. Although unintentional, this requirement inevitably limits efficiency improvement. The market process itself has created a barrier preventing software developers from creating error-free software. The high failure rates of current software are due to the unavoidable fact that software processes have an operational sequence that is fixed. Since process sequences are composed of individual, distinct events with precise start and stop points, each reliant in succession upon the execution of previous steps, the successful execution of software as a whole results. Where the conventional process breaks down is when one or more predefined sequential events receives no input or an invalid input. With the immense complexity of organizational software applications, all designed to avoid duplicate input from data sources, an input error can and often does create an error ripple effect that progresses geometrically throughout the software process. The complexity associated with organizational software applications means that a programmer debugging or designing a work around for a problem uncovered after implementation rarely fixes the problem completely. Rather, since software processing sequences are interrelated and do not execute continuously, a problem considered resolved invariably will reappear when a dependent but rarely used process is invoked by the software process system.
The causes of no input or invalid input for a particular field are numerous and unique to the organization implementing the software process. Since software applications are tied to other systems, the software application typically receives input from users, receives data uploads, and performs mathematical functions to generate data fields. Regardless of the source of inputs, it is a logical conclusion that if the input for any reason whatsoever is unacceptable by the application software at any point in the software process, then the software process as a whole is compromised.
As a result, organizations regularly have to modify processes and procedures to accommodate a particular database application, leading to incompatibility issues for subsequent queries. Further, such database applications require lengthy development and implementation times, which are disruptive to the day-to-day operations of the organizations.
Currently, code is written and compiled into libraries, classes, and executables, converting it to machine code that can be read by computers. Changes to code require the application to be recompiled. When the code is extensive, the complex referencing and use of common classes and libraries introduces significant risk of creating run errors that are difficult to isolate and correct. The storage of compiled code as a result represents a source of code malfunction while imposing a barrier to dynamic customization and construction of a software environment.
Changes to software application currently require significant time and carry a high risk for the reasons listed above. Commercial off-the-shelf (“COTS”) software, because it is compiled as one major application, is not amenable to being customized, requiring customers to adapt their processes to the software, rather than having the software accommodate their processes. Nicholas Carr pointed out this fact in his landmark article “IT Doesn't Matter”, stating boldly that since software forces similar processes on all customers, company strategic abilities are severely limited or even eliminated as a result. Building a system from the ground up is fraught with risk and has been estimated to fail roughly 60% of the time.
Accordingly, there exists a need to provide a process or method of providing a flexible software application structure that integrates with existing processes and procedures of an organization, allowing for dynamic communication between information technology processes and an end user. Dynamic software customization and storage in uncompiled form achieves efficiency goals of an organization.